View Source Front Page JavaScript / DHTML Java Language Netscape Servers Open Standards and Architectures E-Commerce Human Interface Case Studies Third-Party News

DevEdge Online Archive
This page may be OBSOLETE. Bookmark the NEW DevEdge site.
HUMAN INTERFACE ONLINE

Worth the Wait?

By Peter Bickford

Send comments and questions about this article to View Source.   

Allison had read Men Are From Mars, Women Are From Venus, but right now she was trying to figure out which obscure part of the cosmos her company's programmers called home. Quite remarkably, the programmers looked like Earth people, and even spoke in a language that often resembled English. However, as the lead programmer on the other end of the telephone babbled excitedly about the URL he had just sent Allison to, it was obvious that his alien senses were perceiving objects that were invisible to mere humans.

"See! The ordering applet displays the online catalog, lets you select products, and fires off the transactions through the gateway to the main DBMS!"

Allison didn't see. All she could see was an empty square in the middle of her screen. Every time she'd ever come to this part of the system, she'd seen the same blank square. No matter how she squinted at it, it had never looked, to her eyes, the least bit like an online ordering system. It looked like a screen with a big blank patch in the middle of it.

As a result, she'd always clicked on over to other web pages looking for a way to place orders. Despite persistent rumors of its existence, she'd never actually beheld the apparent wonder which was the company's online ordering applet. Neither had most of her company's customers. After she'd made a few calls to technical support, one of the programmers had called to help her out.

A minute of uncomfortable silence passed, and Allison could take no more. "Look, I don't mean to be rude, but what the heck are you talking about? There's nothing there!"

"Oh!" said the programmer, startled that there was a problem. "Well, there will be in a few minutes. It must still be loading."

SPEED MATTERS

For all we know, the company's ordering system was a miracle of wonderfully structured Java code and aesthetically pleasing graphics, with an extraordinarily elegant interface. The truth is, users' satisfaction with a given program is tied more to its speed than to any other factor. Programs that are slow to load, or that respond sluggishly to a user's commands, will find their users moving on to other alternatives. The situation gets even worse in the impatient world of the web, where users are accustomed to time-saving tricks like clicking on links before the page's graphics are fully drawn. Here, as in Allison's case, a slow-loading applet might not appear at all before the user loses patience and moves on.

While computers themselves are increasing in performance at incredible rates, the web remains one of the few areas where speed is hard to come by. For most users, communication speed is pegged at a mere 28.8 Kbps or below, and network delays bog down even those lucky enough to have ISDN or T1 lines. Adding to this, the current implementations of many network browsers and development environments leave much to be desired in terms of performance.

The good news is that although speed matters, perceived speed matters even more. For the most part, the thing that makes users crazy is not the amount of actual time that goes by, but the feeling of waiting -- little delays before the computer reacts to their input, or the long seconds they spend sitting around with nothing to do while the computer works to complete a task. Luckily, although we often can't control the computer's absolute speed, we can employ a number of tricks to make the computer feel faster. At the same time we can also keep the user better informed of what we're doing. The result is that our programs and web pages will seem faster to users, although the actual speed may not have changed at all.

STUPID USER TRICKS

As we go about giving our web pages a speed makeover, there are two critical numbers we need to keep in mind: 200 milliseconds and 8.5 seconds.

The first number, 200 milliseconds -- a mere 0.2 seconds -- forms the mental boundary between events that seem to happen together and those that appear merely as echoes of each other. If a computer program responds less than 200 ms after the user's actions, it will seem fluid and responsive. Any more than 200 ms and the computer will seem frustratingly sluggish. That frustration plays a key role in our second number. To explain it, I'd like to tell you about a little experiment of mine.

For this devious little adventure in science, I recruited almost two dozen expert typists and asked them to fill out a big stack of forms in exchange for a free "Usability Testing" T-shirt. They were told that the purpose of the experiment was to find out what sorts of user interface elements (radio buttons, text fields, pop-up menus, and so on) were the quickest for data entry. Indeed, that was one goal of the experiment. The main purpose, however, was a bit more sinister.

As test subjects showed up for the experiment, I sat them down with a stack of forms to fill out and explained that the computer would be collecting information on their speed and accuracy, and that if they needed anything I could be reached back at my office. After showing them how to fill out a sample form, I started the video camera rolling and left the room.

What the subjects didn't know was that the test was rigged. After the user clicked the Save button on the 28th form, the computer would go into a hard wait loop for two minutes. After that, the program would continue normally.

Of course, nobody ever got that far. Instead, they'd click the Save button repeatedly, grimace a bit, mutter a few unprintables, and then either get up and look for me to fix things, or -- a bit more than half the time -- reach over and reboot the machine. What I was really trying to find out was how long they would wait before they either gave up and rebooted the machine or walked out of the room altogether.

The answer was much shorter than I'd imagined. In the original test, the users weren't given so much as a watch cursor to convince them that the computer was working on their problem. According to an analysis of the video tapes, it took only 8.5 seconds for half the subjects to either walk out or hit the reboot switch. Switching to a watch cursor during the wait delayed the subject's departure for about 20 seconds. An animated watch cursor was good for over a minute, and a progress bar would keep them waiting until the Second Coming -- or Windows 98, whichever came first.

So what does it all mean? First, when the user performs an action, your program needs to respond immediately, even if just to change the cursor. For longer waits, make sure you display some sort of message to let the user know what you're doing and how long it will take. In doing so, avoid relying too heavily on browser status line displays, which are easily overlooked and can change before the user sees them. Above all, keep your users informed -- or it will take only about 8.5 seconds for them to give up on your application.

SPEEDING IT UP

Now that we know the need for perceived speed, how do we go about getting it? Here are a few strategies for making your application seem faster, even if its absolute speed hasn't changed.

React immediately.

With the exception of Java applets, it's going to be hard to live up to the goal of a sub-200 ms response time throughout our web systems. Considered individually, however, most conventional interface elements will do their part when used normally. Buttons will highlight when clicked, text will appear as the user types, and so forth. Only image maps fail to respond in any visible way to a user's actions.

However, on the page level, with all these elements combined, things slow down dramatically. Still, you can greatly boost the perceived speed of your pages by minimizing the use of graphics, or by trimming down -- or using frames to isolate -- the parts that must be redrawn in order to update the page in response to user input.

Do visible work first.

If a complex page is to be displayed, display the top of the page quickly and save complex graphics or other processes for later, while the user is reading. Break up long tables so that the top information can be displayed without forcing the user to wait for the entire table to load. If your system retrieves information from a database, break up your pages so that they retrieve small amounts of data -- say, ten rows per page -- instead of designing a form that retrieves huge amounts of data all at once.

If you write Java applets, structure them to bring up a splash screen or other display as quickly as is technically possible. This will reassure the user that the application is working properly, and it will buy you additional time to load the application before the user becomes anxious.

Let the user move on quickly.

Web pages are inherently asynchronous -- something that undoubtedly plays a large role in their being tolerable at all with low-speed communications. Unfortunately, many web pages force the user to wait for involved graphics to draw in order to see the names of buttons, or they put key navigational elements at the bottom of pages, buried under complex tables and graphics.

Try to locate your navigational elements near the top of the page, or in a separate frame that won't need to be redrawn every time the user moves from page to page. If you use graphics for navigation, always use the <IMG> tag's alt= attribute to provide users with the names of navigation buttons without requiring them to wait for the actual graphic to load. In addition, make sure you've specified the height and width for your graphics so that the browser can draw their bounding areas immediately, and try to use the same images throughout so that the graphics can be cached by the browser and retrieved quickly when needed.

If your system includes image maps, consider using the lowsrc= attribute to immediately load in a black and white or other, more quickly drawn version of the graphic. This will often provide all the information the user needs to move on, although more patient users will see the full-color version automatically as soon as the rest of the page is done loading.

Keep the user posted.

If anything your system does is going to take more than a few moments, make sure you give your users reassurance that all is well, and an idea of how long it will be until you're done.

With straight HTML, you'll have to rely on your web browser's status line for this, limited though it may be. Java applets face additional problems in this area. Their larger size and resource requirements often make them take far longer to load than a standard HTML page. What's more, most browsers do little more than display a blank screen area while the applet is loading, sometimes accompanied by an ambiguous "applet loading" message buried at the bottom of the screen. Luckily, Java applets that go the extra mile can incorporate real feedback mechanisms such as progress bars and other displays to keep the user informed. These involve additional work for the programmer, but they're absolutely crucial if we expect users to wait far beyond the critical 8.5 seconds before the applets begin executing.

WWW Revisited

Really unfunny industry columnists are fond of saying that WWW doesn't stand for "World Wide Web," but for "World Wide Wait." Typically, this is followed by a call for faster gateways, cable modems, or other measures that are well out of our immediate control. No matter how fast communications hardware gets, however, we can count on people pushing it to the limit, doing more things online, and using richer -- and more bandwidth-intensive -- methods of interacting.

It's safe to say there are always going to be times when our users are forced to wait. With a little planning and attention to interface, however, we can make sure the wait won't seem too long. After that, it's up to us to ensure that the value we give our users is well worth the wait.


View Source wants your feedback!
Write to us and let us know
what you think of this article.

Peter Bickford is the principal of Human Computing, a human interface consulting firm in San Jose, California. He's known for his human interface work at Apple Computer, where he wrote the Human Interface column for the developer publication Apple Directions for more than four years. Most recently, he is the author of Interface Design: The Art of Developing Easy-To-Use Software, published by AP Professional.

(10.97)

For the latest technical information on DevEdge Archive products, go to: http://developer.netscape.com

For more Internet development resources, try Netscape TechSearch.


Copyright © 1999 Netscape Communications Corporation.
This site powered by: Netscape Enterprise Server and Netscape Compass Server.